Transparent hypervisor pinning of critical memory areas in a shared memory partition data processing system

ABSTRACT

Transparent hypervisor pinning of critical memory areas is provided for a shared memory partition data processing system. The transparent hypervisor pinning includes receiving at a hypervisor a hypervisor call initiated by a logical partition to register a logical memory area of the logical partition with the hypervisor. Responsive to this hypervisor call, the hypervisor transparently determines whether the logical memory is a critical memory area for access by the hypervisor. If the logical memory area is a critical memory area, then the hypervisor automatically pins the logical memory area to physical memory of the shared memory partition data processing system, thereby ensuring that the memory area will not be paged-out from physical memory to external storage, and thus ensuring availability of the logic memory area to the hypervisor.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.12/403,447, filed Mar. 13, 2009, entitled “Transparent HypervisorPinning of Critical Memory Areas in a Shared Memory Partition DataProcessing System”, which was published on Dec. 10, 2009, as U.S. PatentPublication No. 2009/0307440 A1, and which claims the benefit of U.S.provisional application Ser. No. 61/059,492, filed Jun. 6, 2008,entitled “Virtual Real Memory”, the entirety of each of which isincorporated herein by reference.

TECHNICAL FIELD

The present invention relates generally to data processing systems, andmore particularly, to transparent pinning of critical memory areas inthe hypervisor-managed paging environment of a shared memory partitiondata processing system.

BACKGROUND OF THE INVENTION

Logical partitions (LPARs) running atop a hypervisor of a dataprocessing system are often used to provide higher-level function thanprovided by the hypervisor itself. For example, one LPAR may bedesignated a virtual input/output server (VIOS), which providesinput/output (I/O) services to one or more other LPARs of the dataprocessing system. This offloading of higher-level function avoidscomplex code in the hypervisor, and thus, assists in maintaining thehypervisor small and secure within the data processing system.

Currently, the number of logical partitions (LPARs) that may be createdon a partitionable server of the data processing system is bound by theamount of real memory available on that server. That is, if the serverhas 32 GBs of real memory, once the partitions have been created andhave been allocated those 32 GBs of real memory, no further logicalpartitions can be activated on that server. This places restriction onthose configurations where a customer may wish to have, for example,hundreds of logical partitions on one partitionable server.

Partitioned computing platforms have led to challenges to fully utilizeavailable resources in the partitioned server. These resources, such asprocessor, memory and I/O, are typically assigned to a given partitionand are therefore unavailable to other partitions on the same platform.Flexibility may be added by allowing the user to dynamically remove andadd resources, however, this requires active user interaction, and cantherefore be cumbersome and inconvenient. Also, memory is difficult tofully utilize in this way since there are frequently large amounts ofinfrequently accessed memory in idle partitions. However, that memoryneeds to be available to the operating system(s) to handle sudden spikesin workload requirements.

SUMMARY OF THE INVENTION

To address this need, the concept of a shared memory partition has beencreated. A shared memory partition's memory is backed by a pool ofphysical memory in the server that is shared by other shared memorypartitions on that server. The amount of physical memory in the poolwill typically be smaller than the sum of the logical memory assigned toall of the shared memory partitions in the pool to allow the memory tobe more fully utilized. Idle and/or less active logical memory in theshared partitions that does not fit in the physical memory pool ispaged-out by the hypervisor to a cheaper and more abundant form ofexternal storage via an entity external to the hypervisor known as apaging service partition.

In a partitioned computing environment, the operating systems running inthe partitions register areas of memory with the hypervisor when theyare started. Some of these areas of memory include control blocks orbuffers that are used by hypervisor code. Registered areas that areshared with the hypervisor are deemed critical to the interactionbetween the operating system and the hypervisor. Shared memorypartitions introduce new problems related to the registration and use ofthese areas.

The areas of memory shared between the operating system and thehypervisor must be available to the hypervisor when it needs to accessthem. The hypervisor code using these areas is not allowed to block, andthere is no guarantee that the memory will ever become available. Due tothe nature of shared memory partitions, therefore, a approach is neededto ensure that these memory areas are pinned in physical memory toeliminate the possibility of the memory being paged-out to externalstorage, and not readily available to the hypervisor.

Provided herein, therefore, is a method of pinning a logical memory areato physical memory in a shared memory partition data processing system.The method includes: receiving by a hypervisor of the shared memorypartition data processing system a hypervisor call, the hypervisor callbeing initiated by a logical partition of the shared memory partitiondata processing system to register a logical memory area with thehypervisor; and responsive to receipt of the hypervisor call,transparently determining by the hypervisor whether the logical memoryarea to be registered is a critical memory area for access by thehypervisor, and if so, automatically pinning by the hypervisor thelogical memory area to the physical memory of the shared memorypartition data processing system to ensure availability thereof to thehypervisor by preventing the logical memory area from being paged-outfrom the physical memory to external storage.

In another aspect, a shared memory partition data processing system isprovided. The shared memory partition data processing system comprisesat least one logical partition, which is at least one shared memorypartition, a physical memory comprising a shared memory pool for the atleast one shared memory partition, and a hypervisor interfaced to thephysical memory and to the at least one shared memory partition. Thehypervisor responds to a hypervisor call from a shared memory partitionto register a logical memory area thereof with the hypervisor bytransparently determining whether the logical memory area is a criticalmemory area for access by the hypervisor, and if so, by automaticallypinning the logical memory area to the physical memory, thereby ensuringavailability thereof to the hypervisor by preventing the logical memoryarea from being paged-out from the physical memory to external storage.

In a further aspect, the invention comprises an article of manufacturewhich comprises at least one computer-readable medium havingcomputer-readable program code logic to transparently pin by ahypervisor a logical memory area to physical memory in a shared memorypartition data processing system. The computer-readable program codelogic when executing on a processor performing: receiving at thehypervisor a hypervisor call initiated by a logical partition toregister a logical memory area of the logical partition with thehypervisor; and transparently determining by the hypervisor whether thelogical memory area is a critical memory area for access by thehypervisor, and if so, automatically pinning by the hypervisor thelogical memory area to physical memory of the shared memory partitiondata processing system to ensure availability thereof to the hypervisorby preventing the logical memory area from being paged-out from thephysical memory to external storage.

Further, additional features and advantages are realized through thetechniques of the present invention. Other embodiments and aspects ofthe invention are described in detail herein and are considered a partof the claimed invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The subject matter which is regarded as the invention is particularlypointed out and distinctly claimed in the claims at the conclusion ofthe specification. The foregoing and other objects, features, andadvantages of the invention are apparent from the following detaileddescription taken in conjunction with the accompanying drawings inwhich:

FIG. 1 is a block diagram of one embodiment of a data processing systemto implement one or more aspects of the present invention;

FIG. 2 is a more detailed illustration of a data processing system whichcould be used to implement one or more aspects of the present invention;

FIG. 3 illustrates one embodiment of a data processing system comprisingmultiple shared memory partitions employing a common (or shared) memorypool within physical memory of the data processing system, in accordancewith an aspect of the present invention;

FIG. 4 illustrates one operational embodiment of handling hypervisorpage faults within a shared memory partition data processing system,such as depicted in FIG. 3, in accordance with an aspect of the presentinvention;

FIG. 5 depicts one embodiment of logic for transparently identifying andpinning critical memory areas of a logical partition to physical memoryin a hypervisor-managed paging environment of a shared memory partitiondata processing system, in accordance with an aspect of the presentinvention;

FIG. 6 illustrates one embodiment of a shared memory pool in a sharedmemory partition data processing system having multiple critical memoryareas to be transparently identified, and pinned by a hypervisor usingassociated memory (or page) descriptors, each comprising a hypervisorpin count for the associated logical memory area, in accordance with anaspect of the present invention; and

FIG. 7 depicts one embodiment of a computer program productincorporating one or more aspects of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 is a block diagram of a data processing system 100, which in oneexample, is a symmetric multiprocessing (SMP) server computer system.SMP server computer system 100 includes physical hardware devices thatcan be mapped to, i.e., temporarily owned by, a user application toexecute that application.

SMP server computer system 100 includes a physical SMP server 102.Physical SMP server 102 includes physical hardware devices such asprocessor 104, memory 106, and I/O adapters 108. These physical devicesare managed by hypervisor 110. Processors 104 are shared processors andeach may be a simultaneous multithreading (SMT)-capable processor thatis capable of concurrently executing multiple different threads on theprocessor.

A virtual server is a proxy for a physical server that has the samecapabilities, interfaces, and state. Virtual servers are created andmanaged by a hypervisor that resides on physical SMP server computersystem 100. A virtual server appears to be a physical SMP server to itsuser: the operating system, middleware, and application software thatrun upon it. SMP server computer system 100 includes one or more virtualservers such as virtual server 112 and virtual server 112 a.

Each virtual server appears to its software to include its ownprocessor(s), memory, and I/O adapter(s) that are available for theexclusive use of that virtual server. For example, virtual server 112includes a virtual processor 120, virtual memory 122, and virtual I/Oadapters 124. Virtual server 112 a includes virtual processors 120 a,virtual memory 122 a, and virtual I/O adapters 124 a.

Each virtual server supports its own software environment, including anoperating system, middleware, and applications. The software environmentof each virtual server can be different from the software environment ofother virtual servers. For example, the operating systems executed byeach virtual server may differ from one another.

For example, virtual server 112 supports operating system 114,middleware 116, and applications 118. Virtual server 112 a supportsoperating system 114 a, middleware 116 a, and applications 118 a.Operating systems 114 and 114 a may be the same or different operatingsystems.

A virtual server is a logical description of a server that defines aserver environment that acts, to a user, as if it were a physicalserver, being accessed and providing information in the same way as aphysical server. The virtual processors, virtual memory, and virtual I/Oadapters that are defined for each virtual server are logicalsubstitutes for physical processors, memory, and I/O adapters.

Hypervisor 110 manages the mapping between the virtual servers withtheir virtual processors, virtual memory, and virtual I/O adapters andthe physical hardware devices that are selected to implement thesevirtual devices. For example, when a virtual processor is dispatched, aphysical processor, such as one of physical processors 104, is selectedby hypervisor 110 to be used to execute and implement that virtualprocessor. Hypervisor 110 manages the selections of physical devices andtheir temporary assignment to virtual devices.

Hypervisor 110 services all of the logical partitions during a dispatchtime slice. The dispatch time slice is a particular length of time.During each dispatch time slice, hypervisor 110 will allocate, orassign, the physical processor to each logical partition. When thelogical partition has been allocated time on the physical processor, thevirtual processors defined by that logical partition will be executed bythe physical processor.

Hypervisor 110 is responsible for dynamically creating, managing, anddestroying virtual SMP servers. Whole virtual processors, virtual I/Oadapters, and virtual memory blocks can be removed or added byhypervisor 110. Hypervisor 110 is also responsible for dynamic resourceallocation, managing time-sharing of physical resources, and alteringthe physical resource mapped to a processor without involving theoperating system. Hypervisor 110 is also able to dedicate physicalresources to virtual resources for situations where sharing is notdesired. Hypervisor 110 is responsible for managing the addition orremoval of physical resources. Hypervisor 110 makes these additions anddeletions transparent to the upper level applications.

FIG. 2 is a more detailed illustration of a computer system that may beused to implement the concepts described herein. Data processing system200 may be a symmetric multiprocessor (SMP) system including a pluralityof shared processors or SMT-capable processors, such as processors 202and 204 connected to system bus 206. Alternatively, a single processorsystem may be employed. In the depicted example, processor 204 is aservice processor. Each SMT-capable processor is capable of concurrentlyexecuting multiple hardware threads on the one processor.

Also connected to system bus 206 is memory controller/cache 208, whichprovides an interface to local memory 209. I/O bus bridge 210 isconnected to system bus 206 and provides an interface to I/O bus 212.Memory controller/cache 208 and I/O bus bridge 210 may be integrated asdepicted.

Peripheral component interconnect (PCI) bus bridge 214 connected to I/Obus 212 provides an interface to PCI local bus 216. A number of modemsmay be connected to PCI bus 216. Typical PCI bus implementations willsupport four PCI expansion slots or add-in connectors. Communicationslinks to network computers may be provided through modem 218 and networkadapter 220 connected to PCI local bus 216 through add-in boards.

Network adapter 220 includes a physical layer 282 which conditionsanalog signals to go out to the network, such as for example, anEthernet network for an R45 connector. A media access controller (MAC)280 is included within network adapter 220. Media access controller(MAC) 280 is coupled to bus 216 and processes digital network signals.MAC 280 serves as an interface between bus 216 and physical layer 282.MAC 280 performs a number of functions involved in the transmission andreception of data packets. For example, during the transmission of data,MAC 280 assembles the data to be transmitted into a packet with addressand error detection fields. Conversely, during the reception of apacket, MAC 280 disassembles the packet and performs address checkingand error detection. In addition, MAC 280 typically performsencoding/decoding of digital signals transmitted and performs preamblegeneration/removal as well as bit transmission/reception.

Additional PCI bus bridges 222 and 224 provide interfaces for additionalPCI buses 226 and 228, from which additional modems or network adaptersmay be supported. In this manner, data processing system 200 allowsconnections to multiple network computers. A memory-mapped graphicsadapter 230 and hard disk 232 may also be connected to I/O bus 212 asdepicted, either directly or indirectly.

Service processor 204 interrogates system processors, memory components,and I/O bridges to generate and inventory and topology understanding ofdata processing system 200. Service processor 204 also executesBuilt-In-Self-Tests (BISTs), Basic Assurance Tests (BATs), and memorytests on all elements found by interrogating a system processor, memorycontroller, and I/O bridge. Any error information for failures detectedduring the BISTs, BATs, and memory tests are gathered and reported byservice processor 204.

Those of ordinary skill in the art will appreciate that the hardwaredepicted in FIG. 2 may vary. For example, other peripheral devices, suchas optical disk drives and the like, also may be used in addition to orin place of the hardware depicted. The depicted example is not meant toimply architectural limitations with respect to the present invention.

The present invention may be executed within one of the computers ordata processing systems depicted in FIG. 1 or 2. As a specific,commercially available example, a shared memory partition dataprocessing system implementing hypervisor-managed paging such asdescribed hereinbelow can be built upon technologies found in IBM's p/iSeries product line firmware and systemware, as described in the “PowerArchitecture Platform Reference” (PAPR) material at Power.org(http://www.power.org/members/developers/specs/PAPR_Version_(—)2.7_(—)09Oct07.pdf),which is hereby incorporated herein by reference. In addition, a virtualinput/output server (VIOS) is commercially available as part of aPowerVM computing system offered by International Business MachinesCorporation. The VIOS allows sharing of physical resources betweenlogical partitions, including virtual SCSI and virtual networking. Thisallows more efficient utilization of physical resources through sharingbetween logical partitions and facilitates server consolidation. (IBM,pSeries, iSeries and PowerVM are registered trademarks of InternationalBusiness Machines Corporation, Armonk, N.Y., U.S.A. Other names usedherein may be registered trademarks, trademarks, or product names ofInternational Business Machines Corporation or other companies.).

As noted, partition computing platforms have presented challenges tofully utilize available resources in the partitioned server. Oneapproach to achieving this goal has been the creation of a shared memorypartition data processing system, generally denoted 300, such asdepicted in FIG. 3. As illustrated, the shared memory partition dataprocessing system 300 includes one or more shared memory logicalpartitions (referred to herein as shared memory partitions) 310, each ofwhich comprises one or more virtual processors 320, which interfacethrough a hypervisor, and more particularly, a hypervisor memory manager330, to a shared memory pool 340 within physical memory 350 of theshared memory partition data processing system 300. The amount ofphysical memory in the pool is typically smaller than the sum of thelogical memory assigned to all of the shared memory partitions 310utilizing the shared memory pool to allow the memory to be more fullyemployed. Idle and/or less active logical memory of one or more sharedmemory partitions that does not fit in the shared memory pool 340 ispaged-out by the hypervisor to a more abundant, less expensive storage(such as disk storage), via a paging service partition 360. Pagingservice partition 360 is an enhanced virtual input/output service (VIOS)partition configured to facilitate paging-out and paging-in of memorypages from or to, respectively, the shared memory pool. Also, althoughreferred to as a shared memory partition, in reality, there is nosharing of memory per se between partitions, but rather a sharing of theamount of physical memory in the pool.

FIG. 4 illustrates one operational embodiment of handling hypervisorpage faults within a shared memory partition data processing system suchas described above in connection with FIG. 3. In this embodiment, threeshared memory partitions 310, i.e., shared memory partition 1, sharedmemory partition 2 & shared memory partition 3, are illustrated, eachcomprising one or more virtual processors 320, and each encountering ahypervisor page fault 400. Each hypervisor page fault is responsive to arequest by a virtual processor 320 for memory that is not resident inthe shared memory pool 340 of physical memory 350. Responsive to this,the hypervisor memory manager 330 takes an I/O paging request 420 from afree I/O paging request pool 410 and sends, via the paging servicepartition 360, the I/O paging request to the external storage entity 370to request the needed page. Concurrent with requesting the needed page,the partition's virtual processor encountering the hypervisor page faultis placed into a wait state.

As noted above, the logical partitions (or operating systems running inthe partitions) register logical memory areas with the hypervisor whenthey are started. Some of these areas include control blocks or buffersthat are used by hypervisor code. The registered areas that are sharedwith the hypervisor are deemed critical to the interaction orcommunication between the logical partition and the hypervisor. Sharedmemory partitions introduce new problems related to the registration anduse of these critical memory areas.

The areas of memory shared between the logical partition and thehypervisor must be available to the hypervisor when it needs to accessthem. That is, the hypervisor code using these areas is not allowed toblock, and there is no guarantee that the memory will ever becomeavailable. Due to the nature of shared memory partitions, it istherefore desirable to ensure that these critical memory areas be pinnedin the physical memory associated with the hypervisor to eliminate thepossibility of the memory being paged-out, and therefore not availablewhen needed.

Eliminating the possibility of critical memory being paged-out, and notthus available, prevents a multitude of problems which could occur ifthe hypervisor code were to fault on one of the critical pages. If thehypervisor were to fault, the fault would impact the performance ofother partitions of the system, since the hypervisor would not beavailable to handle the other partitions' requests while the page faultis being satisfied. This also prevents a deadlock scenario where thehypervisor code faults on one of the critical pages, and the pagingservice partition needs to perform an input/output (I/O) recovery to getthe paging device functional and satisfy the paging request. The I/Orecovery is dependent on the higher-level hypervisor, which would befaulted on the critical page, and therefore, the I/O recovery would notoccur and the paging service partition would never be able to handle thepage fault. Further, the solution presented herein avoids possiblefreezing of the hypervisor should the paging service partition becomenon-responsive (e.g., because it crashed), which would otherwise causethe hypervisor to wait indefinitely if it were to fault on a criticalmemory area required from external storage.

One solution to the problem would be to require that critical memoryareas for the hypervisor be defined in the system architecture. In sucha case, the logical partition (i.e., operating system) would need to beaware of the critical memory areas and explicitly request that they bepinned prior to registering a critical memory area with the hypervisor.With such a solution, however, each operating system that runs on thehypervisor would need to track critical hypervisor memory areas.

Advantageously, the solution presented herein eliminates the need forthe operating system (or logical partition) to be aware of which areasare critical to the hypervisor. As the logical partition registerslogical memory areas with the hypervisor, the hypervisor transparentlydetermines which areas are critical memory areas. These memory areas arethen pinned by the hypervisor automatically to ensure that they arealways resident in physical memory. By pinning critical memory areas tothe physical memory, the hypervisor is guaranteed not to fault on thesememory areas. Also, as discussed further below, this pinning does notmean that the critical memory area will remain in the same physicalmemory location.

Generally stated, therefore, provided herein is an approach for pinninga logical memory area to physical memory in a shared memory partitiondata processing system. As illustrated in FIG. 5, the approach includesinitiating by a logical partition of the shared memory partition dataprocessing system a hypervisor call to register a logical memory areawith the hypervisor 500. Responsive to receipt of the hypervisor call,the hypervisor transparently determines whether the logical memory areato be registered is a critical memory area for access by the hypervisor510. If “no”, then the hypervisor executes the hypervisor call toregister the logical memory area 530, which completes the hypervisorcall 540.

If, however, the hypervisor call is a request to register a logicalmemory area which is a critical memory area to the hypervisor, then thehypervisor automatically pins the logical memory area to physical memoryof the shared memory partition data processing system to ensureavailability thereof to the hypervisor by preventing the logical memoryarea from being paged-out from the physical memory to external storage520. After pinning the logical memory area to physical memory, thehypervisor executes the hypervisor call to register the logical memoryarea 530, which completes the processing 540.

In one embodiment, the transparent determination by the hypervisorwhether the logical memory area is a critical memory area for access bythe hypervisor can be accomplished through the design and implementationof the hypervisor. For example, each logical partition utilizes adefined set of hypervisor calls. The design and implementation of thehypervisor includes knowledge of which of these hypervisor calls areused in logic flows that cannot tolerate a page fault, which as noted,occurs when the logical memory area needed during the hypervisor call isnot resident in physical memory. Any control block data structure usedduring these hypervisor calls are therefore critical and must bepersistently resident in physical memory. During the initialization ofthe logical partition, and during certain runtime operations such asadding or removing a virtual processor of a logical partition, thelogical partition invokes a number of hypervisor calls informing thehypervisor of logical memory areas (e.g., control block data structures)which the logical partition will utilize for communication with thehypervisor. If any of these logical memory areas will later be used incritical logic flows between the hypervisor and the logical partition,where the hypervisor cannot tolerate a page fault, then the hypervisortransparently pins the logical memory area to physical memory so that itis accessible to the hypervisor. Therefore, the logical partition (oroperating system) does not need to have knowledge of which logicalmemory areas must be persistently resident in physical memory. Thisprevents having to make changes to existing operating system code whenthe criticalness of the logical memory areas change from update toupdate of the hypervisor.

FIG. 6 illustrates one embodiment of data structures to facilitate thetransparent pinning of selected logical memory areas to physical memoryby the hypervisor, in accordance with an aspect of the presentinvention. In FIG. 6, physical memory 350 is again illustrated, alongwith a shared memory pool 340, such as described above in connectionwith the shared memory partition data processing system of FIGS. 3 & 4.In this embodiment, the shared memory pool 340 includes a plurality ofshared memory areas 600, 601, 602, 603 & 604, each of which may comprise(in on embodiment) one or more logical pages. In the example depicted,logical memory areas 601 & 602 are labeled critical memory areas, asdetermined by the hypervisor, while logical memory area 604 comprises aninput/output (I/O) memory buffer area specified (for example) by thelogical partition.

As illustrated in FIG. 6, the hypervisor associates memory descriptors(e.g., page descriptors) with each logical memory area in the sharedmemory pool of physical memory. In the embodiment depicted, these memorydescriptors comprise multiple pinning counts (i.e., pin counts) whichtrack the number of times the associated logical memory area is pinnedby either the hypervisor or the logical partition owning the logicalmemory area. In the embodiment illustrated, each memory descriptor 610,611, 612, 613 & 614 includes an input/output (I/O) pin count and ahypervisor pin count. The I/O pin count may be controlled by the logicalpartition as pages are mapped, for example, for direct memory access,input/output, etc. In contrast, the hypervisor pin count is controlledonly by the hypervisor. Thus, in the illustrated example, the automaticpinning by the hypervisor includes setting by the hypervisor thehypervisor pin counts in memory descriptors 611, 612 for the associatedlogical memory areas 601, 602, which as noted above were deemed criticalmemory areas. The set hypervisor pin count directs that the associatedlogical memory area be pinned to the physical memory, that is, bedesignated for persistent storage within the physical memory. The memorydescriptors associated with the logical memory areas 600 & 603 do nothave their hypervisor pin count set, and thus, are able to be paged-outto external storage as needed.

Because the transparent pinning approach described herein is performedby the hypervisor, the hypervisor is aware of which logical memory areasin the shared memory pool are considered critical memory areas. Thisknowledge can be employed with other features of the hypervisor, such aspartition mobility or memory defragmentation. Since the hypervisor isaware of where the critical memory areas are in the shared memory pool,the hypervisor can relocate the critical memory areas, for example,either within the shared memory pool, or via partition mobility ormemory defragmentation, if needed, without unpinning the critical memoryareas from the physical memory. This is contrasted with the standardsolution of relocating logical memory areas on the fly by paging thelogical memory areas out to external storage, and letting the logicalmemory areas naturally page back into the physical memory at a newlocation when accessed by the logical partition. This solution would notwork in the present case, since the critical memory areas are pinnedinitially by the hypervisor to the physical memory.

To summarize, transparent hypervisor pinning of selected logical memoryareas to physical memory advantageously avoids having to add code to thelogical partitions (i.e., operating systems) of a shared memorypartition data processing system to enable the logical partitions to beaware of and manage the pinning of these logical memory areas. Thesolution presented herein moves the management of critical memory areasto the hypervisor, which isolates the management of the logical memoryareas in the same place as the enforcement of the pinning of those areasto the physical memory.

Further details on shared memory partition data processing systems areprovided in the following, co-filed patent applications, the entirety ofeach of which is hereby incorporated herein by reference:“Hypervisor-Based Facility for Communicating Between a HardwareManagement Console and a Logical Partition”, U.S. Ser. No. 12/403,402;“Hypervisor Page Fault Processing in a Shared Memory Partition DataProcessing System”, U.S. Ser. No. 12/403,408; “Managing Assignment ofPartition Services to Virtual Input/Output Adapters”, U.S. Ser. No.12/403,416; “Automated Paging Device Management in a Shared MemoryPartition Data Processing System”, U.S. Ser. No. 12/403,426; “DynamicControl of Partition Memory Affinity in a Shared Memory Partition DataProcessing System”, U.S. Ser. No. 12/403,440; “Shared Memory PartitionData Processing System with Hypervisor Managed Paging”, U.S. Ser. No.12/403,459; “Controlled Shut-Down of Partitions Within a Shared MemoryPartition Data Processing System”, U.S. Ser. No. 12/403,472; and“Managing Migration of a Shared Memory Logical Partition From a SourceSystem to a Target System”, U.S. Ser. No. 12/403,485.

One or more aspects of the present invention can be included in anarticle of manufacture (e.g., one or more computer program products)having, for instance, computer usable media. The media has therein, forinstance, computer readable program code means or logic (e.g.,instructions, code, commands, etc.) to provide and facilitate thecapabilities of the present invention. The article of manufacture can beincluded as a part of a computer system or sold separately.

One example of an article of manufacture or a computer program productincorporating one or more aspects of the present invention is describedwith reference to FIG. 7. A computer program product 700 includes, forinstance, one or more computer usable media 710 to store computerreadable program code means or logic 720 thereon to provide andfacilitate one or more aspects of the present invention. The medium canbe an electronic, magnetic, optical, electromagnetic, infrared, orsemiconductor system (or apparatus or device) or a propagation medium.Examples of a computer readable medium include a semiconductor or solidstate memory, magnetic tape, a removable computer diskette, a randomaccess memory (RAM), a read-only memory (ROM), a rigid magnetic disk andan optical disk. Examples of optical disks include compact disk-readonly memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.

A sequence of program instructions or a logical assembly of one or moreinterrelated modules defined by one or more computer readable programcode means or logic direct the performance of one or more aspects of thepresent invention.

Although various embodiments are described above, these are onlyexamples.

Moreover, an environment may include an emulator (e.g., software orother emulation mechanisms), in which a particular architecture orsubset thereof is emulated. In such an environment, one or moreemulation functions of the emulator can implement one or more aspects ofthe present invention, even though a computer executing the emulator mayhave a different architecture than the capabilities being emulated. Asone example, in emulation mode, the specific instruction or operationbeing emulated is decoded, and an appropriate emulation function isbuilt to implement the individual instruction or operation.

In an emulation environment, a host computer includes, for instance, amemory to store instructions and data; an instruction fetch unit tofetch instructions from memory and to optionally, provide localbuffering for the fetched instruction; an instruction decode unit toreceive the instruction fetch unit and to determine the type ofinstructions that have been fetched; and an instruction execution unitto execute the instructions. Execution may include loading data into aregister for memory; storing data back to memory from a register; orperforming some type of arithmetic or logical operation, as determinedby the decode unit. In one example, each unit is implemented insoftware. For instance, the operations being performed by the units areimplemented as one or more subroutines within emulator software.

Further, a data processing system suitable for storing and/or executingprogram code is usable that includes at least one processor coupleddirectly or indirectly to memory elements through a system bus. Thememory elements include, for instance, local memory employed duringactual execution of the program code, bulk storage, and cache memorywhich provide temporary storage of at least some program code in orderto reduce the number of times code must be retrieved from bulk storageduring execution.

Input/Output or I/O devices (including, but not limited to, keyboards,displays, pointing devices, DASD, tape, CDs, DVDs, thumb drives andother memory media, etc.) can be coupled to the system either directlyor through intervening I/O controllers. Network adapters may also becoupled to the system to enable the data processing system to becomecoupled to other data processing systems or remote printers or storagedevices through intervening private or public networks. Modems, cablemodems, and Ethernet cards are just a few of the available types ofnetwork adapters.

The capabilities of one or more aspects of the present invention can beimplemented in software, firmware, hardware, or some combinationthereof. At least one program storage device readable by a machineembodying at least one program of instructions executable by the machineto perform the capabilities of the present invention can be provided.

The flow diagrams depicted herein are just examples. There may be manyvariations to these diagrams or the steps (or operations) describedtherein without departing from the spirit of the invention. Forinstance, the steps may be performed in a differing order, or steps maybe added, deleted, or modified. All of these variations are considered apart of the claimed invention.

Although embodiments have been depicted and described in detail herein,it will be apparent to those skilled in the relevant art that variousmodifications, additions, substitutions and the like can be made withoutdeparting from the spirit of the invention and these are thereforeconsidered to be within the scope of the invention as defined in thefollowing claims.

1. A method of pinning a logical memory area to physical memory in ashared memory partition data processing system, the method comprising:receiving by a hypervisor of the shared memory partition data processingsystem a request to register a logical memory area with the hypervisor;and responsive to receipt of the request, transparently determining bythe hypervisor whether the logical memory area is a critical memory areafor access by the hypervisor, and if so, automatically pinning by thehypervisor the logical memory area to physical memory of the sharedmemory partition data processing system to ensure availability thereofto the hypervisor by preventing the logical memory area from beingpaged-out from the physical memory to external storage.
 2. The method ofclaim 1, wherein the automatic pinning comprises setting by thehypervisor a hypervisor pin count associated by the hypervisor with thelogical memory area, wherein the hypervisor pin count when set preventsthe logical memory area from being paged-out to external storage,thereby pinning the logical memory area to physical memory.
 3. Themethod of claim 2, further comprising associating by the hypervisor amemory descriptor with the logical memory area, the memory descriptorcomprising the hypervisor pin count, and wherein the hypervisor pincount is controlled by the hypervisor only.
 4. The method of claim 1,further comprising receiving by the hypervisor multiple requests toregister multiple logical memory areas with the hypervisor, and whereinthe transparently determining comprises transparently determining by thehypervisor to automatically pin at least one logical memory area of themultiple logical memory areas to physical memory, and to leave unpinnedat least one other logical memory area of the multiple logical memoryareas, wherein the unpinned at least one other logical memory area canbe paged-out from the physical memory to external storage.
 5. The methodof claim 1, wherein the critical memory area for access by thehypervisor is a logical memory area for which the hypervisor by designcannot tolerate a hypervisor page fault, and wherein the logical memoryarea comprises at least one logical page, and a hypervisor page faultmeans that a needed logical page is absent from the physical memory,having been stored to external storage separate from the physical memoryof the shared memory partition data processing system.
 6. The method ofclaim 1, wherein the logical memory area comprises a control block datastructure, and wherein the transparently determining comprisestransparently determining by the hypervisor whether the control blockdata structure is a critical control block data structure for hypervisorcommunication with the logical partition, and if so, automaticallypinning by the hypervisor the critical control block data structure tophysical memory.
 7. The method of claim 1, wherein the transparentlydetermining and the automatically pinning occur without knowledge of alogical partition initiating the request, and wherein the method furthercomprises allowing the hypervisor to relocate the logical memory area inphysical memory after pinning thereof and without unpinning the logicalmemory area to the physical memory.
 8. The method of claim 1, whereinone or more shared memory partitions of the shared memory partition dataprocessing system share a shared memory pool in the physical memory ofthe shared memory partition data processing system, and wherein logicalmemory assigned to the one or more shared memory partitions is greaterthan physical memory assigned to the shared memory pool, and logicalmemory may be paged-out from the shared memory pool to the externalstorage, and wherein the request is initiated by a logical partitioncomprising one shared memory partition of the one or more shared memorypartitions sharing the shared memory pool.
 9. A shared memory partitiondata processing system comprising: at least one logical partition, theat least one logical partition being at least one shared memorypartition; a physical memory comprising a shared memory pool for the atleast one shared memory partition of the data processing system; and ahypervisor interfaced to the physical memory and to the at least oneshared memory partition, wherein the hypervisor responds to a request toregister a logical memory area with the hypervisor by transparentlydetermining whether the logical memory area is a critical memory areafor access by the hypervisor, and if so, by automatically pinning thelogical memory area to the physical memory, thereby ensuringavailability thereof to the hypervisor by preventing the logical memoryarea from being paged-out from the physical memory to external storage.10. The shared memory partition data processing system of claim 9,wherein the automatic pinning by the hypervisor comprises setting by thehypervisor a hypervisor pin count associated with the logical memoryarea, wherein the hypervisor pin count when set prevents the logicalmemory area from being paged-out to external storage, thereby pinningthe logical memory area to physical memory.
 11. The shared memorypartition data processing system of claim 10, wherein the hypervisorassociates a memory descriptor with the logical memory area, the memorydescriptor comprising the hypervisor pin count, and wherein thehypervisor pin count is transparent to the logical partition, and iscontrolled by the hypervisor only.
 12. The shared memory partition dataprocessing system of claim 9, wherein the hypervisor receives multiplerequests to register multiple logical memory areas with the hypervisor,and wherein the transparently determining comprises transparentlydetermining by the hypervisor to automatically pin at least one logicalmemory area of the multiple logical memory areas to physical memory, andto leave unpinned at least one other logical memory area of the multiplelogical memory areas, wherein the unpinned at least one other logicalmemory area can be paged-out from the physical memory to externalstorage.
 13. The shared memory partition data processing system of claim9, wherein the critical memory area for access by the hypervisor is alogical memory area for which the hypervisor by design cannot tolerate ahypervisor page fault, and wherein the logical memory area comprises atleast one logical page, and a hypervisor page fault means that a neededlogical page is absent from the physical memory, having been stored toexternal storage separate from the physical memory of the shared memorypartition data processing system.
 14. The shared memory partition dataprocessing system of claim 9, wherein the logical memory area comprisesa control block data structure, and wherein the transparentlydetermining by the hypervisor comprises transparently determining by thehypervisor when the control block data structure is a critical controlblock data structure for hypervisor communication with the at least oneshared memory partition, and if so, automatically pinning by thehypervisor the critical control block data structure to physical memory.15. The shared memory partition data processing system of claim 9,wherein the transparently determining and the automatically pinning bythe hypervisor occur without knowledge of the at least one shared memorypartition, and wherein the hypervisor is allowed to relocate the pinnedlogical memory area in physical memory without unpinning the logicalmemory area to the physical memory.
 16. An article of manufacturecomprising: at least one non-transitory computer-readable medium havingcomputer-readable program code logic to transparently pin by ahypervisor a logical memory area to physical memory in a shared memorypartition data processing system, the computer-readable program codelogic when executing on a processor performing: receiving at thehypervisor a request to register a logical memory area of the logicalpartition with the hypervisor; and transparently determining by thehypervisor whether the logical memory area is a critical memory area foraccess by the hypervisor, and if so, automatically pinning by thehypervisor the logical memory area to physical memory of the sharedmemory partition data processing system to ensure availability thereofto the hypervisor by preventing the logical memory area from beingpaged-out from the physical memory to external storage.
 17. The articleof manufacture of claim 16, wherein the automatically pinning comprisesautomatically setting by the hypervisor a hypervisor pin countassociated by the hypervisor with the logical memory area, wherein thehypervisor pin count when set prevents the logical memory area frombeing paged-out to external storage, thereby pinning the logical memoryarea to physical memory.
 18. The article of manufacture of claim 17,further comprising associating by the hypervisor a memory descriptorwith the logical memory area, the memory descriptor comprising thehypervisor pin count, and wherein the hypervisor pin count is controlledby the hypervisor only.
 19. The article of manufacture of claim 16,wherein the computer-readable program code logic when executing on aprocessor further performs receiving by the hypervisor multiple requeststo register multiple logical memory areas with the hypervisor, andwherein the transparently determining comprises transparentlydetermining by the hypervisor to automatically pin at least one logicalmemory area of the multiple logical memory areas to physical memory, andto leave unpinned at least one other logical memory area of the multiplelogical memory areas, wherein the unpinned at least one other logicalmemory area can be paged-out from the physical memory to externalstorage.
 20. The article of manufacture of claim 16, wherein thecritical memory area for access by the hypervisor is a logical memoryarea for which the hypervisor by design cannot tolerate a hypervisorpage fault, and wherein the logical memory area comprises at least onelogical page, and a hypervisor page fault means that a needed logicalpage is absent from the physical memory, having been stored to externalstorage separate from the physical memory of the shared memory partitiondata processing system.